Implementation of concurrent programs in object-oriented languages (09-Mar-2010)

TECHNICAL FIELD

This invention is related to generally to computer systems. More particularly, the present invention is directed to a system and methodology which can employ language extensions in an object oriented environment to support asynchronous programming through message passing, contracts, and orchestration.

BACKGROUND OF THE INVENTION

Programming concurrent applications is considered difficult and error-prone by a majority of professional developers. Most system developers struggle with this type of programming which is one reason why it remains outside the reach of most business application developers.

Concurrent algorithms are not always appropriate, however, when used for solving the right problems, they offer tremendous advantages in terms of performance and algorithmic simplicity. With the growing interest in developing programs that are distributed across wide-area networks, the need for concurrent programming tools is increasing as communication latencies grow rapidly and the cost of sequential execution sky-rockets.

One problem is, however, that the facilities for concurrency available to most programmers are low-level and complicated to use. Few programming languages offer any kind of support for concurrency. Conventionally, the programming languages that offer support for concurrency are special-purpose languages or languages that are used only within small academic communities.

Object-oriented (OO) frameworks such as J2EE and .NET brand environments have made the OO approach to program design mainstream. However, with its focus on shared memory, it leads to complex support for concurrency, support that is better suited for system programming than application programming. It is widely recognized that shared memory is one of the main obstacles to simple support for concurrency.

Accordingly, there exists a substantial need in the art to add support for concurrency to a mainstream OO language and to implement coexistence. Further, there is an unmet need for a system and/or method to allow programs to be developed that may either be run in one address space, distributed across several processes on a single computer, or distributed across a local-area or wide-area network, all without recoding the program. Central to this aspect is the notion of a “service”, which executes its own algorithmic (logical) thread. Moreover, there is an unmet need for a means of specifying message-based interfaces between services. In other words, there is a need to unify OO and message oriented languages in order to simplify application programming.

Conventional services with message-passing are defined by OCCAM, a special-purpose language developed in the 1980's which was designed and operable only on a specific hardware processor. Formal program specifications embedded in the programming language are not new. Eiffel, for example, offers a limited form of program specification support directly in the programming language itself. Eiffel is an advanced programming language created by Bertrand Meyer and developed by his company, Interactive Software Engineering (ISE).

However, separation of the protocol specification from the implementation is currently not available. This separation is extremely important to the ability to abstract the interaction of services with each other. For example, XLANG, the language underlying BizTalk, exposes the entire service message-exchange pattern as a protocol. However, this implementation is not separated from the interface, which makes static verification of contract conformance difficult.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

The present invention disclosed and claimed herein, in one aspect thereof, provides a high-level abstraction of concurrency directly in a mainstream object-oriented (OO) language. It offers a concurrency model intended to make writing correct concurrent programs straightforward through the introduction of asynchronous message passing utilizing mechanisms for managing communication between multiple services simultaneously (e.g., orchestration).

In one aspect, the present invention adds support for concurrency to a mainstream object-oriented language. Language extensions are provided that can enable programs to be developed that can either be run in one address space, distributed across several process on a single computer, or distributed across a local-area or wide-area network, without recoding the program. Central to this aspect is the notion of a service, which can execute its own algorithmic (e.g., logical) thread. Accordingly, services do not share memory or synchronize using explicit synchronization primitives. Rather, both data sharing and synchronization is accomplished via message-passing, e.g., a set of explicitly declared messages are sent between services. Messages can contain data that is shared and the pattern of message exchange to provide the synchronization.

In another aspect, a methodology of specifying message-based interfaces between services is provided, e.g., a contract. A mechanism of adding further detail to interfaces (e.g., methods) and contracts is also provided. Such details offer the ability to describe an ordering of method calls (in the interface case) or messages (in the contract case) that can provide a formal protocol definition.

Other aspects of the present invention are directed to distinct contract-related innovations. Contracts are a formal specification of the allowable sequences of invocation of the members of an interface. They are particularly powerful when used with bidirectional message-based interfaces, but their applicability extends to traditional OO interfaces as discussed herein. By way of example, one aspect of the present invention is related to an implementation of a dynamic verification algorithm. More specifically, this aspect is related to a runtime algorithm for enforcement of contracts. Accordingly, regardless of the pattern of the expression, it is contemplated that the runtime representation can be a non-deterministic finite state machine encoding all legal contract states. This state machine can then be used to validate method invocations or messages against the contract specification.

Another aspect of the present invention is related to the introduction of explicitly declared messages in an OO language. While conventional systems employing message-oriented languages are known, the explicit declaration of directed, payload-carrying, messages is novel, as is its combination with OO concepts. Particularly, as discussed herein, the concept of message-passing is novel to OO languages, and quite distinct from the traditional concepts. Expressing a protocol as a set of methods or directed messages of temporal ordering of methods or messages is described according to another aspect. More particularly, this aspect of the innovation pertains to the addition of formal contracts to OO languages (e.g., VB.NET brand environment). By using the declared messages or methods as an alphabet of a pattern, one can establish a simple but sufficiently formal protocol definition of a communication protocol.

The contract concept can be augmented with a mechanism to achieve the same kind of software reuse as inheritance in relation to object-oriented languages. Particularly, one main concept is contract extension, whereby an asymmetrical compatibility between generations of contracts is achieved. By way of example, this concept enables a client using an older version of a contract to communicate with a service that has been updated to use a newer version.

Further, the present invention is directed toward orchestration. Accordingly, in order to handle the asynchronous needs of message-oriented programs, an aspect of the present invention adds language constructs that support several concepts of “safe” parallelism. Because the model is loosely coupled, it can support distribution of program components. Some of the benefits are programmer productivity in programming asynchronous applications, reliability of developed applications, and overall readability of application source code.

For ease of understanding, the described aspects of the present invention are directed to Visual Basic (VB) concepts related to the following keywords: Service, Send, Receive, Select Receive, Wait, Split, Timeout, Inner Services, Begin, Catch Receive, Accept, Split Select Receive. Combined, the new language construct can implement a model for handling messages in parallel with each other. It is contemplated that the present invention can support loosely coupled concurrency and co-routines for tightly coupled parallelism. These constructs are discussed in further detail later in this text.

A compilation algorithm can be utilized in accordance with aspects of the present invention. Specifically, the compiler's approach to breaking the co-routine-based code down into pieces to allow parallel waits to occur without blocking thread context is another novel aspect of the present invention. Each place in the source code that could potentially block the current thread while waiting for a message to arrive can be broken apart to allow multiple such points to wait in parallel, or alternatively, the thread context to continue with some other computation. To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention can be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a general component block diagram of a orchestration system in accordance with an aspect of the invention.

FIG. 2 illustrates a flow chart of procedures to facilitate message passing in an object-oriented environment in accordance with an aspect of the disclosed invention.

FIG. 3 illustrates a general component block diagram of a contract component in accordance with an aspect of the invention.

FIG. 4 illustrates a flow chart of procedures to facilitate the declaration of a contract in accordance with an aspect of the disclosed invention.

FIG. 5 illustrates a flow chart of procedures to facilitate contract extensions in accordance with an aspect of the disclosed invention.

FIG. 6 illustrates a general component block diagram of an orchestration component in accordance with an aspect of the invention.

FIG. 7 illustrates a block diagram of a computer operable to execute the disclosed architecture.

FIG. 8 illustrates a schematic block diagram of an exemplary computing environment in accordance with the present invention.

Appendix A is a paper entitled Stuck-Free Conformance. This appendix forms part of the subject specification.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It may be evident, however, that the present invention can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the present invention.

As used in this application, the terms “component”, “system” and “mechanism” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers.

Following is a description of various aspects of the present invention. It should be noted that although the present disclosure is discussed in relation to aspects employing the present system and method in a Visual Basic (VB) environment, it will be appreciated that the concepts disclosed herein can be employed in connection with any object oriented (OO) environment without departing from the spirit, scope or functionality of the present invention.

Generally, one aspect of the present invention is directed to a system and methodology which can employ language extensions in a VB.NET brand environment to support asynchronous programming through message passing, contracts, and orchestration. In short, in accordance with disclosed aspects of the present invention, VB orchestration allows one to describe a protocol and code a service or client accordingly. It will be appreciated that the present invention alleviates the need to explicitly code and manage conversational state.

Referring initially to FIG. 1, a general block diagram of an object-oriented system 100 in accordance with an aspect of the present invention is shown. As earlier stated, for ease of understanding, the system 100 will be described herein directed toward a VB application. Although the VB environment will be primarily used to discuss aspects of the invention, it is to be appreciated that the system 100 can be applied to any known object-oriented language without departing from the scope of the invention described herein. Generally, system 100 can be configured to include a client 102, a contract component 104, an orchestration component 106, and a plurality of target services 108₁-108_N, where N is an integer. It will be appreciated that target services 108₁-108_N will be collectively referred to hereinafter as target services 108.

The contract component 104 can include a payload carrying message or set of messages and a protocol which identifies an implementation schedule for the message(s). It will be appreciated that the contract component can alternatively be directed to the transfer of methods or a set of methods.

Orchestration component 106 can be configured to interpret the contract and to facilitate parallelism and/or concurrency of services 108. For example, the orchestration component 106 can be configured facilitate the handling of multiple messages as well as multiple targets of a message(s). Although novel to the invention, it will be appreciated that the orchestration component of FIG. 1 enhances the underlying novel concepts and innovations of unifying object-oriented and message-oriented environments via message passing to/from services.

FIG. 2 illustrates a methodology for exchanging contracts and messages in accordance with an aspect of the present invention. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, e.g., in the form of a flow chart, are shown and described as a series of acts, it is to be understood and appreciated that the present invention is not limited by the order of acts, as some acts may, in accordance with the present invention, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the present invention.

At 202, a contract is declared—as described herein, it will be appreciated that declaration of the contract can include defining a plurality of messages or methods as well as an optional pattern of deployment. At 204, the message (or methods) embodied within the contract is sent to a target service. Next, at 206, the message (or methods) is received and transition is provoked. Finally, the message is accepted at 208 and subsequently decompiled at 210 in order to implement the contract and to employ the code included within its message(s) and/or method(s).

Concurrency Model

Referring again to FIG. 1, it should be noted that the concurrent execution with shared state between the client 102 and services 108 has proven to be problematic for even skilled programmers. While various forces push and pull software towards concurrent execution and asynchronous interaction between the client 102 and services 108, difficulties in achieving correctness are impediments. The present invention is directed to a system and/or methodology that employs a concurrency model to mitigate some of the complexities in writing correct concurrent programs.

Contrary to conventional implementations, in the exemplary VB orchestration of the present invention illustrated in FIG. 1, no two lines of execution that share in-memory state execute concurrently. As illustrated, the present invention employs the services 108 to facilitate concurrent execution. The services do not share state with any code outside of the individual service. Additionally, to accomplish asynchronous communication, the present system illustrated in FIG. 1 utilizes a contract component 104 or “message passing” technique, which appears in the language as explicit Send and Receive operations and embodied within the orchestration component 106.

It will be appreciated that the introduction of asynchronous message passing requires mechanisms for managing communication between multiple services simultaneously. Accordingly, the collection of mechanisms for coordinating communication between concurrent services is termed “orchestration” and employed by the orchestration component 106 of FIG. 1.

As will be discussed in further detail below, language mechanisms are provided that introduce pseudo-parallel execution (e.g., Split). However, these mechanisms actually provide concurrent waiting rather than concurrent execution. The combination of the services 108 and orchestration component 106 provides concurrent and asynchronous behavior without the risks of race conditions and unsynchronized memory accesses. In accordance with the present invention, an exchange of messages between two services occurs as a conversation governed by the contract component 104. Contract component 104 provides specifications of the messaging behaviors of services 108, and allows an individual service 108 to be checked for some forms of correctness (e.g., conformance with patterns of message exchange, freedom from deadlock) without access to the implementations of the services with which it interacts. Thus, it will be appreciated that a primary artifact in understanding the behavior of a service is its implemented contract.

Contracts

With reference to FIG. 3, essentially, a contract 104 can be defined as interface declarations for asynchronous message-passing, with richer semantics. In other words, a contract utilizing a message component 302 to specify a set of messages (or methods) and an optional protocol or pattern component 304 that describes allowable sequences of message exchange. Additionally, contract component 104 can employ a contract extension component 306 that extends an existing contract component.

FIG. 4 illustrates a methodology 202 for declaring a contract in accordance with various aspects of the present invention. As described herein, it will be appreciated that declaration of the contract can include defining a plurality of messages or methods as well as an optional pattern. Referring to FIG. 4, and proceeding to 402, a contract type is declared. Specifically, in accordance with the VB example, a contract declaration creates two VB types, representing the client and server perspectives on the contract. For example, a declaration “Contract C” creates the type “C” (representing the client perspective) and the type “Implements C” (representing the server perspective). By way of example, following is an exemplary contract for an alarm clock service:

	Contract AlarmClock
	In Message Set(t As TimeSpan)
	In Message Cancel( )
	Out Message Alarm( )
	Pattern
	Start:
	Set --> Alarm Set
	AlarmSet:
	Cancel --> End
	Alarm --> AlarmSet
	End Pattern
	End Contract

Additionally, below is the contract for an alarm clock service that extends the contract to add a snooze capability:

	Contract SnoozeAlarmClock
	In Message Snooze( )
	Pattern
	AlarmSet:
	Snooze --> AlarmSet
	End Pattern
	End Contract

In order to provide context and for ease of understanding, a discussion of the grammar and semantics of a contract is provided below. By way of example,

ContractStatementGroup →
ContractStatement [ ExtendsOrElaboratesStatement ]
{ HostsStatement } { ContractElementStatement } [
PatternStatementGroup ] { ContractStatementGroup }
EndContractStatement
ContractStatement →
CONTRACT Identifier
EndContractStatement →
END CONTRACT
ExtendsOrElaboratesStatement →
ExtendsStatement |
ElaboratesStatement
ContractElementStatement →
MessageStatement |
ContractStatementGroup |
TypeDefinition
MessageStatement →
MessageDirection MESSAGE Identifier [ ParameterList ]
MessageDirection →
IN |
OUT
PatternStatementGroup →
PatternStatement {StateTransitionStatementGroup }
EndPatternStatement
PatternStatement →
PATTERN
EndPatternStatement →
END PATTERN
StateTransitionStatementGroup →
StateStatement { NameTransitionStatement }
[ OthersTransitionStatement ]
StateStatement →
Identifier [ OVERRIDES Name ] :
NameTransitionStatement →
[ NameTransitionExpression ] --> StateTarget { AND StateTarget }
NameTransitionExpression →
NameTransitionOperand [ NameTransitionOperator
NameTransitionExpression ]
NameTransitionOperand →
Name |
( NameTransitionExpression ) |
[ ANY ] MessageDirection MESSAGE
NameTransitionOperator →
THEN |
AND
OR
StateTarget →
[ IMMEDIATE ] Name |
END |
STOP

As earlier discussed with reference to FIG. 3, a contract can specify a set of messages 302, and, optionally, a pattern 304 describing allowable sequences of message exchange, and/or a contract extension 306 as illustrated in FIG. 3. It should be noted that if no pattern 304 is specified, all sequences of the specified messages are permitted. A contract extension mechanism 306 is a for adding to a contract such that a conversation between a connector typed using the elaborated contract and one typed using the elaborating contract is possible.

With reference again to FIG. 4 and proceeding to 404, a message can be declared. Next, at 406, a pattern can optionally be specified. The pattern specified in 406 can be specified as a state machine. The states can be named by the labels in the StateTransitionStatementGroups. In the alarm clock example above, the starting state is named “start”. Message sends and receives as well as executions of other contracts provoke transitions in the state machine. It is contemplated that if a StateTransitionStatementGroup includes more than one StateTransitionStatement, then the pattern allows any one of the transitions in the group.

At 408 a trigger used in connection with the pattern can be defined. Specifically, a name to the left of the arrow in a MessageTransitionStatement is a trigger, and can name a message or a contract. Next, at 410 a target is identified. An identifier to the right of the arrow is a target, and can name a state. If there are no triggers, then the transition occurs if a trigger of a target state occurs. If a trigger is a contract, the effect is to execute a new instance of the contract's pattern. If there is more than one target, then the transition is to all of the targets in parallel. This situation is referred to as a split transition. If a target is Immediate, the transition occurs when the first trigger begins, rather then when the last trigger completes. It should be noted that this is especially useful when a trigger is a contract.

In accordance with an example, the state

	S0:
	M1 Then M2 --> S2
	is equivalent to
	S0:
	M1 --> S1
	S1:
	M2 --> S2
	Likewise, the state
	S0:
	M1 Or M2 --> S2
	is equivalent to
	S0:
	M1 --> S2
	M2 --> S2
	Additionally, the state
	S0:
	M1 And M2 --> S3
	is equivalent to
	S0:
	M1 --> S1
	M2 --> S2
	S1:
	M2 --> S3
	S2:
	M1 --> S3

Those skilled in the art will appreciate that “Or”, “And”, and “Then” have the same precedence relation as “Or”, “And”, and “AndAlso” respectively in the expression syntax.

In one aspect, a trigger given as “In Message” or “Out Message” can represent any message declared in the contract traveling in the appropriate direction. In another aspect, a trigger given as “Any In Message” or “Any Out Message” represents any message traveling in the appropriate direction, and can be a message not declared in the contract.

A given state can make at most one transition for a given trigger. In accordance with the present system and method, if a state makes a transition for a message, the state accepts the message. A state can accept more than one message, and the messages accepted by a state do not necessarily all travel in the same direction. For example, if all messages do not travel in the same direction, the target state for any message accepted by state S that does not accept all messages accepted by S that travel in the opposite direction ignores those messages.

A transition to End terminates the current line of the state machine. A transition to Stop terminates all lines of the state machine. It should be noted that, in the absence of split transitions, End and Stop are equivalent.

Referring again to FIG. 4, in accordance with the present system and method, messages can be sent and received through connections. A connection is a datum with a type that is a contract type declared at 402. It will be appreciated that the contract type can be specified by naming the contract. On the other hand, a connection can be a datum with a type that is a contract implements type. Contract implements types can be specified by preceding the name of the contract with the designation “Implements”. A connection with a contract type can send In messages and receive Out messages. A connection with a contract Implements type can send Out message and receive In messages.

Split Transitions

If at 410 a state transition has more than one target, then the transition is referred to as a split transition to all of the targets in parallel. For example, a split transition merges partially at a state S if some paths from the split transition converge at S, and merges completely if all paths do. If a state T is a direct or indirect target of a split transition, there cannot be a path to T that does not go through the split transition unless the split transition has completely merged at or before T. If a split transition merges at state S, no transition from S is possible until all paths from the split transition have arrived at S. Informally, splits/merges properly nest, and no transition into the middle of a split/merge is possible.

By way of example:

The pattern

	Pattern
	Start:
	M1 --> Start And S1
	M2 --> S2
	S1:
	M3 --> S3
	S2:
	M4 --> S3
	S3:
	M5 --> End
	End Pattern

accepts the sequence of messages M1, M1, M2, M4, M3, M3, M5. Each split transition that includes S1 requires an M3 to transition to the merge state S3, so there can be an equal number of M3 and M1 messages.
The pattern

	Pattern
	Start:
	Con1 --> Immediate S1 And S2
	S1:
	M1 --> End
	S2:
	M2 --> End
	End Pattern

allows M1 to be intermixed with the messages of Con1, but requires that M2 occur after Con1 completes. It should be noted that this pattern also illustrates that End can be a merge state.
Contract Extension

In accordance with the present system and method, at 412 a contract extension mechanism (e.g., 306 of FIG. 3) can be employed to add to a contract such that a conversation between a connector typed using the elaborated contract and one typed using the elaborating contract is possible. Only one end of the conversation has a choice about which contract to use. The determination is made by the type of extension.

An example of the grammar and semantics is as follows:

ExtendsStatement→

EXTENDS Name

Here, the name in an Extends statement can name a contract that is not the containing contract or a contract that extends or elaborates the containing contract.

If contract B extends contract A, then:

• • All messages of A are messages of B.
  • All states of A are states of B.
  • All contracts hosted by A are hosted by B.
  • B cannot remove any transitions from the states it has inherited from A.
  • B can add messages, states, and hosted contracts.
  • B can add transitions to the states it has inherited from A. All of the added transitions can be for messages traveling in the same direction. For example, if the added transitions are for In messages, a client can connect to a service implementing B using either A or B. If the added transitions are for Out messages, a client can connect to a service implementing A using either A or B.

In program text, a state of A is repeated in B only if B adds transitions to it, and only the added transitions appear. It is to be noted that, in a design, the inherited transitions are visible, but visually marked as immutable.

Connectors

With reference again to FIG. 2, in accordance with the present system and method, an exchange of messages between acts 204 and 206 takes place via a connection. The code at each end of the connection sends and receives messages through a connector which is created via a connector factory. For a contract type CT, a client-side connector has type CT, while a server-side connector has type Implements CT.

Orchestration

Further, a Split operation generates multiple lines of execution, any one of which executes until it yields, at which point any of the others can run. Various language operations can cause a line of execution to yield. Among these are Receive (e.g., wait for a message to arrive) and Wait (e.g., wait for a specific interval of time).

A set of methods form an orchestration unit, or can be said to orchestrate together, if a yield in one of them can allow a line in another to execute. Note that this does not allow execution to proceed past a method call until the call returns. The instance methods of an orchestration class (including those in base and derived classes) orchestrate together for a given instance.

An orchestration class is declared with an “orchestration” modifier. An orchestration class cannot have shared methods or properties. In accordance with the aspect, orchestration operations are VB statements and, subject to some restrictions, can appear in any method.

With reference again to FIG. 2, at 204, a Send statement can be configured as follows:

	SendStatement →
	SEND [ TO Expression ] SendMessageDescriptor
	SendMessageDescriptor →
	SendSpecificMessage |
	SendMessage
	SendSpecificMessage →
	Identifier [ ( Arguments ) ]
	SendMessage →
	MESSAGE Expression

In accordance with the aspect, a Send statement sends a message through a particular connector, which is an optional expression. An absent connector expression can imply that the message will be sent through the primary connector, and is permitted only within a service. It will be appreciated that the connector expression can be of a contract or contract implements type.

If present, the identifier can name a message of the contract, and the message can have the appropriate direction. Similar to a method call, the arguments are type checked against the parameters of the message.

If the Message keyword is present, the expression can be convertible to System.MessageBus.Message, and identifies the message object to send.

Similarly, at 206, a Receive statement can be configured as follows:

	ReceiveStatement →
	ReceiveClause
	ReceiveClause →
	RECEIVE [ FROM Expression ] ReceiveMessageDescriptor
	[ WHEN Expression ]
	ReceiveMessageDescriptor →
	ReceiveSpecificMessage [ ReceiveMessage ] |
	ReceiveMessage
	ReceiveSpecificMessage →
	Identifier [ ( { ReceiveParameterList } ) ]
	ReceiveMessage →
	MESSAGE ReceiveParameter
	ReceiveParameterList →
	ReceiveParameter {, ReceiveParameterList }
	ReceiveParameter →
	Identifier [ AS GeneralType ]

A Receive statement can receive a message through a particular connector, blocking until the message arrives. An absent connector expression implies that the message will be received through the primary connector and is permitted only within a service. The connector expression can be of a contract or contract implements type, the identifier, if present, can name a message of the contract, and the message can identify the appropriate direction. Parameters declared in a Receive statement are scoped similar to local variable declarations. Additionally, parameters that are not declared in the receive statement can be declared as local variables elsewhere.

If the Message keyword is present, the associated parameter can be declared as System.MessageBus.Message, and the Receive can assign the received message object to the local variable. If the Message keyword is present and no specific message name is given, the Receive can receive any message that satisfies the filter expression, if present.

As well, if present, the When expression in a Receive acts as a Boolean filter. If a filter expression is present, the message is received if the filter evaluates to True and otherwise it is ignored until some other Receive consumes it. The filter expression can access the parameters of the receive clause that it is attached to and members of the received message object, but no other non-constant declarations. An absent filter expression is equivalent to a filter expression that always has the value “True.”

For example, a Receive statement of the form

	Receive From C Mumble(P As T)
	NextStatement( )
	is equivalent to
	Dim P As T
	Select Receive
	Case Receive From C Mumble (P)
	End Select
	NextStatement( )
	A Wait statement can be configured as follows:
	WaitStatement →
	WAIT Expression

A Wait statement blocks execution for the specified interval of given by the expression, which can be of type System.TimeSpan. A Wait statement allows a line of execution to yield, even if the interval is zero.

A wait statement of the form
Wait Span
NextStatement( )
is equivalent to
Select Receive Within Span
Case TimeOut
End Select
NextStatement( )
Note: it is important that Threading.Thread.Sleep( ) not be used
inside orchestration code as it can block the thread without allowing
another line in the orchestration to run.
Once received, transition can be provoked at. A Begin statement
can be configured as follows:
BeginStatement →
BeginClause
BeginClause →
BEGIN Identifier TypeAndInitializer

The identifier can be declared as a local variable. The type of the variable can be a contract type or a contract implements type. An initializer can be present.

A Begin statement waits for the beginning of a conversation that is governed by the specified contract. Those skilled in the art will understand that a Begin statement represents a sort of in-line service. Such a conversation begins when another body of code creates a connector of the inverse of the contract type and then sends a message through that connector. When the conversation has begun, the initializer is evaluated, its value assigned to the variable, and execution proceeds.

Begin provides a mechanism for correlating subconversations. For a correlated subconversation, the initialization of the connector is a New expression with a connector as its sole argument. The connector at the other end of the connection will have been created by a New expression with a connector as its sole argument. As well, the two connectors supplied as arguments will have been connected.

A Begin statement of the form
Begin C1 As New CT(C0)
NextStatement( )
is equivalent to
Dim C1 As CT
Select Receive
Case Begin C1 = New CT(C0)
End Select
NextStatement( )
Finally, the message can be accepted at 208. Accordingly,
an Accept State Statement can be configured as follows:
AcceptStateStatement →
AcceptStateClause
AcceptStateClause →
ACCEPT [ FROM Expression ] Identifier

An Accept State statement waits until a connection transitions to a particular contract state. An absent connector expression can imply that the state will be accepted through the primary connector, and is permitted only within a service. The connector expression can be of a contract or contract implements type, and the identifier can name a state of the contract's state pattern.

An accept state statement does not consume any messages. In particular, the message that caused the state transition is not consumed. Unblocking requires a state transition. If the connection is already in the named state when an accept state statement begins, the accept state statement waits until the connection reenters the state.

It will be understood that the accept state statement can be particularly useful as part of the select receive statement, as well as part of the catch accept statement.

An accept state statement of the form
Accept From C S
NextStatement( )
is equivalent to
Select Receive
Case Accept From C S
End Select
NextStatement( )
A Select Receive Statement can be configured as follows:
SelectReceiveStatementGroup →
SelectReceiveStatement { CaseReceiveStatement {
ExecutableStatement } } [
CaseTimeoutStatement { ExecutableStatement } ] EndSelectStatement
SelectReceiveStatement →
SELECT RECEIVE [ WITHIN Expression]
CaseReceiveStatement →
CASE CaseReceiveClause { , CaseReceiveClause }
CaseReceiveClause →
ReceiveClause |
BeginClause |
AcceptStateClause
CaseTimeoutStatement →
CASE TIMEOUT

It will be appreciated that a SelectReceive statement can receive one (or more) of a set of messages (each of which can be through different connectors), and/or starts one or more conversations, and/or accepts states of one or more connections, or times out, and executes the body of code associated with the message(s)/conversation(s)/state(s) or the timeout. The timeout expression must denote a time span.

If more than one CaseReceiveClause is present in a CaseReceiveStatement, all clauses can be satisfied to trigger execution of the body of code associated with the case.

A Split statement can be configured as follows:

	SplitStatementGroup →
	SplitStatement { SplitLineStatement { ExecutableStatement } ]
	EndSplitStatement
	SplitStatement →
	SPLIT
	EndSplitStatement →
	END SPLIT
	SplitLineStatement →
	LINE

A Split statement can suitably divide execution into logical lines of execution. The lines can execute sequentially in lexical order, except that whenever a line blocks waiting for a message the next unblocked line runs. It will be appreciated that no two lines of a Split statement ever execute concurrently. A Receive statement within a line of a Split cannot receive replies to messages sent from another line of the Split. Those skilled in the art will understand that this enables correlating replies to specific messages.)

A Split For Each Statement can be configured as follows:
SplitForEachStatementGroup →
SPLIT ForEachClause { ExecutableStatement } NextStatement
The body of a SplitForEachStatementGroup can be executed as if
each iteration were a separate line of a SplitStatementGroup. Complete
iteration through the collection can occur before executing the body.
A Split Select Receive Statement can be configured as follows:
SplitSelectReceiveStatementGroup →
SPLIT SelectReceiveStatement { CaseReceiveStatement {
ExecutableStatement } } [
CaseTimeoutStatement { ExecutableStatement } ] EndSelectStatement
A Split Select Receive statement automatically creates any
number of lines of execution to handle received messages,
initiated conversations, and timeouts.
A Split Select Receive statement of the form
Split Select Receive
Case Receive M From C
Receive M1 From C
End Select
is similar to, though subtly and significantly different from
Do
Select Receive
Case Receive M From C
Receive M1 From C
End Select
Loop

A Split Select Receive statement can be activated whenever a line yields, rather than waiting for a line to finish. A transfer of control by any line to a point outside the split select receive can terminate all other lines of the split select receive.

A Catch Receive Statement can be configured as follows. A try statement can have handlers that receive messages. A new form of catch statement can be used to implement this concept.

	CatchReceiveStatement →
	CATCH ReceiveClause

A Catch Accept State Statement can be configured as follows. A try statement can have handlers that accept states of connections. A new form of catch statement be used to implement this concept.

	CatchAcceptStateStatement →
	CATCH AcceptStateClause

New Exit Statement are contemplated. For example, new exit kinds can be Line and Split. These apply within Split, Split For Each, and Split Select Receive statements, and are not permitted elsewhere. An Exit Line statement can terminate a line of execution in a Split. An Exit Split statement can exit a Split and terminate all other lines of the Split.

Any other transfer of control that exits any form of Split can have Exit Split semantics, not Exit Line semantics.

Services

Again with reference to FIG. 2, next the contract is implemented at 210. In accordance with the present invention, a service (e.g., service 108 of FIG. 1) provides an implementation of a contract. A service is instantiated automatically upon receipt of an initiating message of the service's contract. The connector through which a service implements its contract is initialized automatically, is available implicitly for sending and receiving messages, and can be referred to explicitly as “Primary”. In accordance with the described aspect, a service can have an instance method named “Run” that has no parameters and returns no result thus, activating the service calls Run.

A service is an orchestration class that derives directly or indirectly from RuntimeService. If no base class is specified, it is implicitly RuntimeService.

Referring again to the alarm clock example earlier presented a service that implements the alarm clock contract given above can be configured as follows:

	Service DecentAlarmClock
	Implements AlarmClock
	Sub Run( )
	Receive Set(T As TimeSpan)
	Select Receive Within T
	Case Receive Cancel( )
	Case TimeOut
	Send Alarm( )
	Receive Cancel( )
	End Select
	End Sub
	End Service

Additionally, below is an exemplary service configured to implement the snooze alarm clock contract of the earlier example:

	Service NicerAlarmClock
	Implements SnoozeAlarmClock
	Sub Run( )
	Receive Set(T As TimeSpan)
	Do
	Try
	Wait T
	Send Alarm( )
	Receive Snooze( )
	T = SnoozeInterval
	Catch Receive Cancel( )
	Return
	End Try
	Loop
	End Sub
	End Service

Turning now to the grammar and semantics of a service:

ServiceStatementGroup →
ServiceStatement { ServiceMemberStatement } EndServiceStatement
ServiceStatement →
SERVICE Identifier
EndServiceStatement →
END SERVICE
ServiceMemberStatement →
ServiceStatement |
MessageStatement |
ClassMemberStatement

In accordance with the above, a service cannot have both an implements statement and any message statements. However, if an implements statement is present, there will be one, it can name a single type, and that type can be a contract.

A service can have an implied primary connector, which implements a contract. The implemented contract can be named in an implements statement. If a service is declared without an implements statement, then the service can declare the messages that can pass through its primary connector, and a pattern will be derived from the service's methods. In other words, any service implements a contract.

The primary connector can be available within the service as Primary. If the connector expression is omitted from a Send or Receive statement, the connector can implicitly be Primary.

A call to a service returns a new instance of a connector typed as the service's implemented contract.

Turning now to a more general discussion of the present invention, when one speaks of clients and servers in an n-tier or in any general distributed context, it is important to define the terms very strictly to avoid confusion. For example, in a VB environment, “service clients” are those orchestration objects that are not started by a message being sent. In other words, a service client can be started in some other way. On the other hand, a “service” is any object that is created by a message being sent to it. It will be appreciated that there is no other way to start a “service.” As a somewhat looser concept, a “client” is any piece of code, whether service or service client, which initiates communication with a service.

Contracts

Referring again to contracts generally, contracts can be used in OO languages (e.g., VB) to specify a protocol and its messages. This discussion will focus on three parts: contract import statements, message declaration statements and a single pattern definition statement as shown below:

	Contract CtRequestResponse
	In Message Request(Question As String)
	Out Message Response(Answer As String)
	Pattern
	Start:
	Request Then Response → End
	End Pattern
	End Contract

Above is a definition of an inbound message called “Request” that will pass a String along. Likewise, an outbound message called “Response” is defined that will also pass a String along. Note that the message itself is a name and not a “clump” of data. Rather the message itself is an identifier for it, similar to a class name in that regard. The data can be defined as parameters of the message.

In addition, also defined is that the protocol allows only two messages in any “session:” a Request and a Response. The directions of the two messages in the interaction are implied by the respective message declaration. It will be appreciated that one person's inbound message is another person's outbound message. In accordance with the present invention, this perspective is from the perspective of the service that implements the contract.

Each interaction over a protocol consists of two parties interacting, sending messages back and forth thereby affecting each other's internal state or having some external effects that are useful. In each such coupling of two parties, for clarity, the parties are labeled the implementing party and the using party.

In VB orchestration of the disclosed aspect, this is referred to as contract perspective. It is to be appreciated that that the compiler will not allow an inbound message to be sent by the implementing party or received by the using party, nor will it allow an outbound message to be received by the implementing party or sent by the using party.

One might observe that the above contract is essentially the complexity that any synchronous message-passing mechanism allows: one message goes one direction, and another comes back as a response. If there is no return data, or any parameters on the procedure call, then the corresponding messages are adjusted accordingly, but there is always one single inbound message followed by one single outbound message in the synchronous pattern. As will be discussed below, protocols can be defined in a large variety of ways, and VB orchestration can facilitate full programmatic access to this powerful technology.

Essentially, employing contracts permits declaring messages and patterns. However, contracts can add a tremendous level of security and robustness to any protocol implementation, as they can allow the compiler to check that the protocol is being adhered to by the code. At a minimum, contracts are enforced at runtime, and often at compile time.

In accordance with the present invention contracts are one of the fundamental language additions in VB orchestration of the disclosed aspect. Below is a continued discussion of details related to contract declaration.

Message Declarations

With reference again to FIG. 4, the example above illustrates a methodology to declare contracts. Specifically, at 404, an act of declaring a message is illustrated. Those skilled in the art will appreciate that they essentially share similar general rules as Sub declarations, with the following constraints:

1. All parameters that are “ByVal.” “Optional,” “ByRef,” or “ParamArray” declarations are not allowed;

2. For any protocol that will be used remotely, all parameters are serializable;

3. All messages have to have a direction specified; and

4. Messages cannot be overloaded.

Pattern Declarations

Turning now to pattern declarations at 406, the most basic building block of any pattern declaration is a message reference. In the above example, one will appreciate that it is only necessary to mention the name of the message when referring to it in a pattern. This is because its direction is well known. Additionally, overloading is not permitted, and additional restrictions cannot be placed on messages beyond the direction and parameter types once it has been declared. It should be noted that there is, for example, no way to specify that the string arguments in the above example have to be non-null, if that is a restriction that is desired.

Patterns are declared by defining a set of named “states” of the protocol, e.g., different positions in the conversation that have some meaning to it. The first state of any pattern can be called “Begin.”

Once the states are defined, the protocol can be completed by adding state “transition” to indicate how the protocol state may change. It will be appreciated that triggers and targets can be identified in connection with acts 408 and 410. In one aspect, such transitions are triggered by messages. In other aspects, the messages can be represented by methods or an imported contract.

By way of example,

	Contract CtRequestResponse
	In Message Request(Question As String)
	Out Message Response(Answer As String)
	Pattern
	Start:
	Request Then Response → End
	End Pattern
	End Contract

As set forth above, the phrase “Request Then Response” is a transition trigger, and “End” the transition's end state. Transition triggers can in other words be composite. For example, composite transition triggers can be employed either by sequencing a set of messages using “Then” or by grouping them unordered using “And.” As well, it is also possible to specify an alternative set of triggers using “Or” between message names. The transition occurs as soon as all the messages of the trigger have been sent or received.

Transition end states can be more than one state. For example, a transition can “split” into two or more target states, which means that the protocol “position” is defined by more than one named state at once. In one aspect, a target end state can also have the modifier “Immediate” attached, which means that the transition to that state occurs immediately upon matching a particular trigger rather than waiting for the full trigger to complete. This is particularly useful when the trigger contains contract names.

As previously discussed, it will be appreciated that a contract that does not have any pattern allows any message exchange pattern; a contract that has an empty pattern allows no messages to be exchanged.

Contact Extension

Additionally, aspects of the present invention employ contract extensions as illustrated in FIG. 4 at 412. FIG. 5 illustrates a methodology that facilitates extending a contract. By extending a contract in accordance with the methodology, a new version can be created that is asymmetrically compatible with the old one. Specifically, when extending a contract, at 502, new messages can be added. As well, at 504 new states can be added to the existing pattern. In addition, new triggers can be added to existing states at 506, subject to some constraints as follows:

• • 1. No ambiguities can be introduced.
  • 2. No existing triggers can be altered.
  • 3. Triggers added to existing states cannot have both “In” and “Out” messages as the first possible messages: the message direction is to be the same.
  • 4. If a trigger is added to an existing state, and if the trigger is an “In” message, then all triggers added to any existing state contain only “In” messages.
  • 5. Conversely, if a trigger is added to an existing state, and if the trigger is an “Out” message, then all triggers added to any existing state can contain only “Out” messages.

In accordance with these constraints, the model for contract reuse can be similar to inheritance for classes. In one aspect, (e.g., only “In” messages are added to existing states), the new contract is client-compatible, and in the other case, it is service-compatible.

A client-compatible contract means that the service can be upgraded from the old contract to the new without clients having to know. In other words, a client using the old contract will never send messages that trigger transitions to new states. On the other hand, a client that is aware of the newer contract can utilize it only if the service supports it. Thus, it will be appreciated that this relationship is an asymmetrical compatibility.

On the other hand, if the contract is service-compatible, then clients can be upgraded to use the new contract and continue to have conversations with services that support either the old or new contract.

Below are examples utilizing a modified version of the earlier presented request/response example:

	Contract CtRequestResponse
	In Message Request(Question As String)
	Out Message Response(Answer As String)
	Pattern
	Start:
	Request → S1
	S1:
	Response → End
	End Pattern
	End Contract

Client-Compatible Example:

	Contract CtRequestResponse1
	Extends CtRequestResponse
	In Message RequestInt(Question As String)
	Out Message ResponseInt(Answer As Integer)
	Pattern
	Start:
	RequestInt → S2
	S2:
	ResponseInt → End
	End Pattern
	End Contract

As set forth in the exemplary code above, if a client only is aware of the old contract, then it can still connect to a service that supports the new contract, since as long as the new messages are never sent, the contracts are interchangeable. As shown above, the service will not be able to discern the difference between a client that uses the old contract and one that simply does not avail itself of the new features.

Service-Compatible Example:

	Contract CtRequestResponse2
	Extends CtRequestResponse
	Out Message ResponseInt(Answer As Integer)
	Pattern
	S1:
	ResponseInt → End
	End Pattern
	End Contract

Here, the service can determine whether to go beyond the existing contract or not. Accordingly, the upgraded client will not be able to tell whether the service uses the old contract or the new one. Note that in the extended pattern only new information is listed: new states and new triggers for existing states. This avoids a source of errors, and if clarity is necessary, the old contract pattern can be included as comments.

It will be understood that a contract A may extend contract B by adding hosted contracts and no messages. In this case, A is symmetrically compatible with B. Hosting contracts will be discussed in more detail later in this text.

Connectors

Contracts can be employed to declare something that refers to them. In accordance with the exemplary aspects, the object that VB orchestration-based code uses to communicate with other code is called a “Connector.”

As far as type is concerned, Connectors are contract reference types. There are peculiarities about Connectors. For example a Connector has a well-defined contract perspective which is a part of its type. It either represents the implementing side of the contract, or the using side. An implementing connector cannot be assigned to a using connector, or vice versa. In accordance with these rules, it is reasonable to wonder how one creates connectors, and how one defines whether it is implementing or using.

Connectors can be created using connector factories which can be defined by the runtime (e.g., VB runtime). Most connector factories are created from service URLs or other connectors:

Dim cFact As ConnectorFactory (Of CtRequestResponse)=ServiceURL

The URI here is called the service reference. It can be some well-known URI kept in a configuration file, or it could be put together at runtime by some other brokering service. For example, there might be a wholesale distributor bidding service that determines the location of the best deal is and sends the URI to that distributor back to the requester.

Once one has a connector factory, Connectors can be created with ease using a conversion operator that is built into the connector factory class:

Dim Connector_—1 As CtRequestResponse=cFact

This exemplary statement creates a using-perspective connector referring to the service addressed by the connector factory and which can implement “CtRequestResponse” on its primary connector. This usage of connector factories can generate using-side connectors.

It will be understood that a connector factory can also be bound directly to a connector of implementing perspective as follows:

Dim cFact As ConnectorFactory (Of CtRequestResponse)=Connector 4

This aspect can be useful in circumstances where it is well-known that both sides are in the same application domain and will not need to be broken apart. As it requires adding code into the application that will prevent it from being distributed, it is generally discouraged, but useful for performance in special cases. The previous examples are using-perspective connectors.

On the other hand, implementing connectors can be declared different in two ways. Specifically, the contract name can be modified by the keyword “Implements” and the initializer expression has to be a contract invocation with no arguments as follows:

Dim Connector_—4 As Implements Ordering=Ordering( )

When a using-perspective connector is initialized, it is bound to the corresponding implementing connector, but an implementing connector does not initiate binding, so it does not need a service reference as a parameter. The resulting connector is thus unbound after being created, and cannot be used for sending messages until some using-side connector has bound itself to the new connector.

Note that a service, as defined earlier, has an implicit implementing connector called its “primary” connector. It is created by the runtime algorithm before the service is started, and available to the schedule as the “Primary” field. In sending and receiving messages, the primary connector can be implied when no other connector is referenced, so one rarely sees any code that actually refers explicitly to the primary connector. As described in detail below, the primary connector can be employed to create a service reference for multiplexing.

Connectors can be declared wherever variables of reference type can be declared. For example, connectors can be declared as locals, as parameters, and/or as fields, in VB Modules, or the like. They can be passed by reference, and copied to other variables, similar to any object reference. In accordance with an aspect of the present invention, the connector's perspective cannot ever be altered. As well, the compiler can ensure this through its strong typing. In the aspect, it is therefore not permissible to use “Option Strict Off” in any source file that defines or uses connectors, or services in general.

Sessions

One novel aspect regarding orchestration of the present invention is that it can reduce concern regarding threads, processes, or other aspects that are typical issues with scalable multi-threaded applications. With proper care and foresight, threading and process isolation can become an application distribution and management problem instead of an application development problem.

However, one concept that is not typically a problem with relation to non-distributed applications, but that is essential to VB orchestration, is the concept of a session.

The following example is provided for ease of understanding. A user that has employed the Internet to shop or access into a financial institution site to access account information or pay bills should be familiar with sessions in the distributed application sense. Particularly, when the e-commerce site is accessed and items are added to a shopping cart, or the “My Account” page is accessed, the web site software has to allocate some objects in memory so that it can remember the visitor and what has been done since the time of logging in. This data can be temporary and different from the order information or account information that persists over a long time which is typically stored in a database.

The lifetime of this temporary data is called a session. In a non-distributed application, data can be kept in memory until it becomes garbage. On the other hand, the situation is wholly different in distributed applications. In relation to distributed applications there are two primary problems. First, object references across application nodes do not exist. And secondly, one cannot count on being advised when a session is concluded.

The first point implies that if one counted on garbage collection to clean up objects, then all the temporary data would look like garbage very quickly and be removed. The application node would then forget everything about the visitor having been there before, which would be cumbersome. Therefore, such software can allocate session-specific data structures, typically in a global collection of some sort and retrieves it when a new request comes in for the same session.

Now turning to the second point, if one does not know when the session is over the session data will never become garbage, as global collections are famous for the memory leak issues that they create.

To address these issues, sessions are typically timed. A timer can be set when the session is first created, and the reset on every incoming message or request. If it can be determined that the session is over, such as the web user logging out, the data is removed at that point. If that cannot be determined, then when the timer goes off, the session data is removed from the global hash table and the data becomes garbage.

It will be understood that the determination of a reasonable timeout interval is completely application-dependent. Web sites typically set the timeout interval at between 10 and 30 minutes, but that is not a universally valid setting. For some applications, a couple of seconds might be appropriate, and for others a few hours.

In accordance with exemplary VB orchestration, all of this is automatically supported. In one aspect, there is a default timeout value of 10 minutes. If 10 minutes is not appropriate, one can reconfigure the timeout in the App.config file. This reconfiguration is discussed in more detail below in with regard to “App.config Settings”.

When a schedule is first started, whether it is a service or service client, its session can be created before anything else happens. The session effectively an instance of the service class. However, it is also assigned a globally unique identifier which allows clients to refer to it. Accordingly, the session is also called the service instance. It will be appreciated that the latter can be particularly useful when the need to indicate that one is referring to a specific object in memory, while the former can be particularly useful when one desires to look at it from the distributed application perspective.

A service instance typically has a number of connectors associated with it. Initially, connectors can be tied only to the schedule that created them, but in order to send messages to another schedule, connectors can be bound to other connectors, always of the same contract but opposing perspectives. Once bound, a connector cannot be rebound.

With reference to the examples above, the first three connectors created are all bound when the service or contract call returns. In the fourth case it is not. This is because the connector can only be used to create a service reference that some other connector uses to bind to. Once that has occurred, communication may start.

In the web service example above, it is important that the software handling the session does not store references to objects that are session-specific outside the session itself. Doing so means that when the session is removed, those objects do not become garbage and one of the main purposes of sessions, to control the lifetime of objects in distributed applications is violated.

It is equally important that this be done when programming VB orchestration, even if the entire application is at first within the same application domain. Allowing references created during a session to be stored outside the schedule will not allow the automatic management of global system resources that will ultimately determine whether the application can be made to scale or not.

The rule is simple—only store references to data state in references that are declared within the body of the service or schedule. In other words, do not store them in global variables or collections of any kind. This rule is easy to follow and very reasonable. As well, this rule is very similar in nature to basic reentrancy rules for other software. For example, avoid global state, instead, always pass data along as parameters.

Only if the data belongs as application-level data, that is, data to be shared among sessions in an application domain, should it be declared and stored outside the session. Even then, it should serve as a red flag that there might be something about the design of the application that needs rethinking.

Schedules (Orchestration)

Now with reference to FIG. 6, a general block diagram of an orchestration component is shown. As shown, an orchestration component can be illustrated to include an implementation or schedule component

1. A system for implementing a service concurrency model for services constructed using an object-oriented language through use of language extensions in a message-oriented language, the language extensions extending a functionality of the services that execute in an object oriented environment so as to unify the object-oriented and message-oriented languages through message passing between a plurality of services, the system comprising: a memory; and a processor, operatively coupled to the memory, the processor executing computer executable components comprising: a plurality of services constructed using the object oriented language; a contract component that facilitates communication among the plurality of services, the contract component defined as interface declarations for asynchronous message passing between the plurality of services, the contract component being represented in source code in each of the plurality of services as express send and receive operations, the contract component including: a message component, the message component declaring a set of messages that can be used as an alphabet for patterns used to establish formal protocol definitions for a communication protocol; and a protocol component, the protocol component describing allowable sequences of message exchange in accordance with formal protocol definitions for a communication protocol; an orchestration component, the orchestration component configured to interpret the contract component and to facilitate the handling of a plurality of messages and a plurality of message targets in the plurality of services, the orchestration component including: a compiler component, the compiler component configured to implement a compilation algorithm to break the source code of the services down into pieces to allow parallel waits to occur without blocking thread context of the plurality of services, the compilation algorithm breaking apart the source code that could block a thread to allow one of: multiple points in the source code waiting in parallel or a thread context continuing with a different computation; and wherein the orchestration component directs the compiler component to generate a schedule for at least a subset of the plurality of services in accordance with the contract component, the schedule facilitating parallelism of the subset of services by allowing services in the subset to wait in parallel with other services in the subset.

2. The system of claim 1, the protocol component comprising: a pattern component that identifies an order that specifies a valid sequence of the asynchronous message component.

3. The system of claim 1, wherein the contract component includes at least one method call component and a pattern component that identifies an order that specifies a valid sequence of the at least one method call component.

4. The system of claim 3, wherein the valid sequence identifies a yield point in the execution of at least one of a method call in the at least one method call component and allows execution of the other of the at least one of a method call to proceed past the yielded method call.

5. The system of claim 1 further comprising a contract extension component that extends the contract component to add at least one additional message to the contract component.

6. The system of claim 5, wherein the contract extension component extends the contract component to add at least one additional state to the contract component.

7. The system of claim 5, wherein the contract extension component extends the contract component to add at least one additional trigger to the contract component.

8. The system of claim 1, wherein a service from the subset of services waits in parallel independently of the other services so as to prevent blocking the execution of other services.

9. At a computer system including a processor and system memory, a method being executed by the computer system for implementing concurrency among a plurality of services represented in object-oriented code, the method comprising: declaring a contract external to the plurality of services, the contract for synchronizing information sent between target services within the plurality of services to implement concurrency for the target services, the contract declaring: a plurality of messages for synchronizing information between target services; and message ordering between a subset of the target services; and enforcing the message ordering in accordance with the external contract among the subset of target services, the enforcement of the message ordering orchestrating asynchronized information among the subset of target services to facilitate target services concurrency, including: a first service in the subset of target services sending a message to a second service in the subset of target services, the message including a payload indentifying an implementation schedule to organize the plurality of services in a parallel manner to accomplish sharing and synchronization of the data for the external contract, the schedule allows for waiting for more than one asynchronous message in parallel thereby preventing the block of thread context of services the payload indicating when the first and second service are to wait without blocking other services; the second service receiving the message from the first service; and the second service decompiling the message in order to employ the payload and implement the schedule for the contract.

10. The method of claim 9, wherein declaring a contract comprises declaring at least one asynchronous message.

11. The method of claim 10, wherein declaring a contract comprises specifying a pattern for execution of at least one asynchronous message.

12. The method of claim 10, wherein enforcing the contract comprises specifying a trigger for execution of the at least one asynchronous message.

13. The method of claim 10, wherein enforcing the contract comprises: dissecting the contract to facilitate generation of a schedule; partitioning the dissected contract to generate the schedule; and communicating the schedule to a runtime algorithm.

14. The method of claim 9, wherein enforcing the contract comprises declaring a method call and specifying a pattern for invocation of the method call.

15. The method of claim 9, wherein the enforcing the contract comprises identifying a contract extension that expands the existing contract.

16. The method of claim 15, wherein identifying the contract extension comprises adding at least one additional message to the contract.

17. The method of claim 15, wherein identifying the contract extension comprises adding at least one additional state to the contract.

18. The method of claim 15, wherein identifying the contract extension comprises adding at least one additional trigger to the contract.

19. At a computer system including a processor and system memory, a method being executed by the computer system for employing an orchestration component to manage communication between a plurality of services, the method comprising: declaring a contract external to the plurality of services, declaring the external contract including defining a plurality of messages and defining a protocol of the external contract for implementing concurrency among the plurality of services, the plurality of messages including more than one of an asynchronous message with data; implementing the external contract for communicating among a plurality of services, each of the services includes a thread context; compiling the external contract to generate a schedule as a function of asynchronous messaging and the protocol of the contract for implementing concurrency among the plurality of services; and using the generated schedule to organize the plurality of services in a parallel manner to accomplish sharing and synchronization of the data, the schedule allows for waiting for more than one asynchronous message in parallel thereby preventing the block of thread context of services, including: sending a message to a service in the plurality of services, the message including a payload identifying the schedule, the payload indicating when the service is wait without blocking other services; and the service decompiling the message in order to employ the payload and implement the schedule to wait without blocking other services.

20. The method of claim 19 further comprising communicating the schedule to a runtime algorithm.