Wednesday, September 23, 2015

Predictions of new trends in software development

I haven't blogged in a while, so I figured I should start something new.  I am going to publish a series of predictions related to software development or related topics.  For the time being, I will use this blog still.  My work involves Scala, Akka, Java, NoSQL, and a variety of other technologies, so that will tend to influence my thoughts on what is to come.  So, on with the first prediction...

Prediction 1, September 23, 2015

Java 8 is more than a year in production, and Oracle is getting ready to stop support of Java 7, Java 9 is right around the corner.  I predict that little of the lambda and stream processing functionality will be adopted by the Java community at large.  Sure there will be pockets here and there, but I think it will take a bit more of a nudge for people to change their way of thinking.
I do imagine that people with experience in other languages that support functional programming will actually come to Java, but not in large numbers.  I don't know how it will be measured, but I am sure some group will try to determine the adoption of the new features of Java 8.  I am thinking that it won't be until 2017 or later.

Wednesday, April 18, 2012

Don't Pollute Your Domains

Good software tries to model and implement the various needs of a system or application apart from each other.  This is called "separation of concerns".  A concern can be many things, but in general, it is a concept.  In AOP, Aspect Oriented Programming, there is an ability to actually code a concern that crosscuts many locations in an application as a single entity.
This capability allows a developer to write code that does not have duplication (DRY, don't repeat yourself).  It is likely that requirements for your system are written by a business analyst, not a computer scientist.  This means the person may likely know many things from software development such as terminology from security.  The gravity of an agile world encourages us to "keep it simple".  This means a requirement will be written in an allegedly simple way, incorporating security features into a business operating feature.  This attempt at simplifying things by uniting security concepts with application concepts, leads to "domain pollution".  That is the domain of the business is all that the SME (Subject Matter Expert) writes.  Well, this leads to domains that are abominations.  Animals aren't just created by declaring this dear needs to have wings because it may run out of food sources, so we need it to be able to get to this other area for food.
You, the developer will have to untangle the real security concern from the business concern.  If the requirements can be expressed in a way that utilizes terminology form different specific domains, then this blending can be stopped.  And we will reduce the needless smashing and untangling of concepts all because it was thought to be simpler.

Friday, November 05, 2010

When Metaphors Go Bad

I have a problem, sometimes I think too much, but I don't ever accuse you of thinking too much or "over"engineering or "thinking" too early. But, I have been wondering about these new ways software is recommended to be developed. This installment of this series will analyze the consequences of the use of the term "grow" as applied to creating software.
The reason a certain term is chosen must be because it is meaningful to the audience. So certainly the agricultural software development community must be what is intended. But what does it mean to grow software?
1. mold grows
2. flowers grow
3. a crop grows
4. a tree grows
If I missed the intended grow item, can you let me know?
Mold? well, I don't really think that is desirable in any way whatsoever?
Flowers? Ok, flowers can be really pretty, but they don't serve much use except for making seeds, are seeds really the nuggets we desire?
A crop? Well, maybe that is it, we raise a crop of software so we can sell it and make lots of money?
A tree? Well, a tree is a beautiful creation of nature, it converts carbon dioxide into oxygen, we create houses and fire out of the wood, hmmm.
I don't think any of that was really planned.
But we might think of building software, like a building, but how can we apply agile principles to growing a building? it will just get bigger, that is how building grow, um, wait a minute, I will save "build" as my next installment.

Tuesday, October 06, 2009

Enhance Exceptions with Context

Don't you wish sometimes that Java had the feature for exceptions to automatically capture the values of the variables in the context that were present when an exception occurs? Well I guess we just have to do it manually. Let's see what it would look like:

public class SomeClass {
public void someMethod(String x) {
try {
int pos = x.indexOf("abc");
String y = x.susstring(pos);
} catch (RuntimeException e) {
throw new RuntimeException(
"there was a problem here, with param x="
+ x, e);
}
}
}

Ok, now whenever someone calls someMethod("noa-b-c"); they will get a friendly message in the exception telling them what the value of x was during the invocation. That wasn't too bad, but what if the method had 3 parameters? What if you didn't have the try block around the whole body and it still threw an exception?

There must be a better way? I don't want to always tell the computer how to do things, how come I can't just say what I want? I want to tell Java that when an exception happens in my method, it should capture the context and chain the original exception. I will just use an annotation to tell Java to do this for me.
public class SomeClass {
@ThrowsContext
public void someMethod(String x) {
int pos = x.indexOf("abc");
String y = x.substring(pos);
}
}

There, that is better! Um, wait, how is that going to work? Now I am going to have to make something that will process that annotation and put the try catch there and include the parameter values. I could run my code in some sort of container that I can proxy the object of SomeClass and in the proxy I can add this new feature, then I need to make sure that all my clients to this method go through the proxy, then oops, I need to use CGLIB because I didn't use an interface, man, that is goign to all be easy.

There must be a better way! AspectJ is still Java, let's see if that wil work. We can create a pointcut for methods that have the @ThrowsContext annotation, and after the method throws an exception, we will chain it with our exception with a message of the context and chain teh original exception.

public aspect ExceptionContext {
pointcut ctx(ThrowsContext t, Object th) :
execution(@ThrowsContext * *..*(..)) &&
@annotation(t) &&
this(th);

after(ThrowsContext t, Object th)
throwing(RuntimeException e) : ctx(t, th) {
Object[] args = thisJoinPoint.getArgs();
throw new RuntimeException("parameters: " +
Arrays.toString(args) + "\nthis=" +th, e);
}
}

That is pretty to the point, it says what I want to do which makes programming more productive and fun. Maybe you don't want the context to leak out of your components, but you need this information to support debugging durign development, you can use LTW Load Time Weaving supported by AspectJ to only add this aspect behavior during deployments that you decide should have it.

Next time we will enhance the context and provide options to which context to include.


And here is the annotation:
@Retention(value=RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ThrowsContext {
}

Wednesday, March 11, 2009

Refactor classes to be domain clean

The beauty of object oriented programming is that you can have a program that resembles the real world objects that it is to represent. Domain driven design is the notion that you create models based on a "domain". That is a subject area. This can be fuzzy, or it can be industry agreed upon. The catch is that you are writing an application, and not a domain model. What does that mean? It means that you will be tempted to add fields to your classes that meet your application's needs, but are not really part of your domain.
Transcendental Beans is here to save you from polluting your domain model with application schemata. You have the power of AspectJ introduction to separate application schema from domain schema.
Try aspect refactoring with AspectJ on your persistent classes with Transcendental Beans

Monday, March 09, 2009

Introduce JAXB to your POJOs

Suppose you want to keep your POJO really a POJO? If you use JPA annotations on a class, is it still really a POJO? A POJO should be usable as a domain object independent of whether it came from a database, or from a remote service. So If I see @Entity on your POJO, I know it is really a database object, and I start thinking all about it's dependencies, do I need a transaction, do I need a JDBC connection, what JAR has the JPA annotation, maybe it isn't in my JRE, no more a "plain" Java object.

Ok, but I want to store my POJO in a database, what do I do? Ok, that will be my next article... Today, what if I want to use JAXB to serialize the POJO as XML? Then I need to use @javax.xml.bind.annotation.XmlRootElement to annotate the class. That just ruined my POJO. AspectJ can add fields, methods, annotations, and parents to classes. Why not just introduce the JAXB annotations necessary to marshal the object at runtime just for the situation that I need?

Here is my POJO:
public class Order {
private String number;
private String product;
private String customerEmail;
private String customerName;
}


Now, here is the POJO with the JAXB annotation:
import javax.xml.bind.annotation.XmlRootElement;
@XmlRootElement
public class Order {
private String number;
private String product;
private String customerEmail;
private String customerName;
}


Isn't marshaling an object to XML a totally different concern from if an Order needs the customer's email address? So, let's separate those two concerns:

import javax.xml.bind.annotation.XmlRootElement;
@XmlRootElement
public aspect Jaxbify {
declare @type : Order : @XmlRootElement;
}

This aspect introduces the XmlRootElement annotation to the Order class, keeping Orders, Orders.
Next time I'll show how to run this example.

Monday, August 25, 2008

test

some text



public class MyClass {
private String myfield;
}

Wednesday, December 05, 2007

How Important is Symmetry in JPA?

When you are designing a domain model using JPA or hibernate or another declarative approach to ORM, you must decide the cascade rules for creating and deletign objects that are related to each other. When you have a one-to-many relationship between two objects, when an object is persisted, you need to decide if the related object should be automatically persisted as well, or should you have to persist each object?
To me it seems that this must be made symmetrical, that is if you cascade create, then you should cascade delete as well. Any other rule than this makes your system more complicated. Intuition should be available to one trying to understand your domain model, and symmetry is a part of nature, so it will be intuitive to expect a consistent behavior. If you are using JPA, the cascade rules will be in the code so you will see the rule with the code so it will be evident of your choice. In the case that you are using Hibernate from an XML configuration file that is not visible at the same time as the source code, then you will have to remember the cascade rules, minimizing the burden of memorizing too many things can help in comprehending your model, a consistent rule of always cascade create with delete will eliminate this from your efforts.
In a more encapsulated direct approach, I recommend that a new annotation of @Aggregation be created that has this behavior as it's meaning, it is simple and precise as to the intent. AspectJ can be used to create this annotation, and with JPA annotations as the ORM approach, the needed annotations can be injected behind the scenes. This seems like a nice clean use of AOP to help in using of JPA.

Sunday, August 05, 2007

Is-a vs. has-a

When you model your system in object oriented methodologies, you have to choose whether a class "is-a" a certain type or if it "has-a" a certain type. Is this confusing? The best way to think of this is to ask what is a customer? If you have a class "Person" in your model, then you might think that a "Customer" is-a "Person". But that starts to get complicated. A customer is someone who has bought a certain product. So, can you scale the is-a version of customer to purchasing of multiple products? Maybe you can model a customer as an order that has been fulfilled, and a person can have a collection of orders, thus a person "has-a" collection of orders. But many situations involving two different products do not occur at the same time usually, so you would preferr to just treat the person as a customer while in the situation involving a certain product.
Then you could have the best of both worlds. But what system or languatge can handle this? You would always have to have some sort of layering and pretend that the other stuff doesn't matter while on the boundaries of the layer. What if there was a DBMS that could let you define both simple versions of person and customer, and the DBMS would integrate the various views as real objects?
An AODBMS would be able to define various dimensions of the same entity and provide a way for the simplified dimensional slice to integrate the various views into a single database entity.

Tuesday, May 22, 2007

Introduction to Aspect Query Language

In this document we will discuss a new query language called "aspect query language" which allows you to write queries against Transcendental Beans, the aspect oriented database. AQL is similar to other query languages in that it starts with a familiar select style syntax. It has results and condition where clauses. The results from an AQL query can be an instance, a reference to the result, a bean instance derived from the query result, a collection of one of these, or an aspect of one of these results. What does that mean? An aspect can be thought of as data that lives in another dimension, but is united by the AODBMS.

A schema is defined in a variety of ways, the motivations of which are to satisfy different roles of users. For example take the definition of a person:

class Person

String name

String phoneNumber

Suppose that you want an application to monitor who changes the values of a person? You might want to add a field modifiedBy to the Person class. This seems fine for the one application, but what about another application that wants to update another database with changes that come from the person database? This application might need to add a field timeModified to the person class:

   class Person     String name     String phoneNumber     String userId     Date timeModified 

Not Person is getting messy. There are three distinct applications that have contributed to the definition of Person. What about the next application trying to "reuse" person? More fields gett added for every usage context. This becomes a maintenance nightmare, coordinating the other consumers to update their usage and all. An RDBMS can provide seperations for some of these concerns, but isn't a Person supposed to describe things about a person? These fields timeModified and modifiedBy are some sort of metadata about Person, but not really "person" fields.

Maybe a better approach would be to seperate these fields from the domain object of Person, an aspect can be defined that introduces needed fields to support the concern of the aspect, so maybe the Person should look like this:

@ChangeTracked

@Audited

class Person

String name

String phoneNumber

This seems a little better, Person is clean, but it is annotated with these other concerns. Even better would be to support this annotation to a class in the AODBMS DML?

annotate Person ChangeTracked, Audited

Now, all the applications can live without even knowing about each other.

What about getting that data back? AQL can be used to retrieve the metadata from the AODBMS by asking for the aspect in teh result specifier:

select aspect(Audit) from Person where name = 'mike'

returns the userId that modified the definition of person last.

Monday, March 19, 2007

Technical White Paper

Application Architecture using a Native Aspect Oriented Database

Level: Intermediate

March 16, 2007

Version 1.0

Abstract: The architecture of an application is chosen to enable the development of the software that achieve the goals of the business at hand. Many times an architecture is chosen from a pattern or template of common architectures such as MVC or SOA. An architecture is created to achieve specific goals usually controlling complexity. Tools are created to achieve the same goal as well. An Aspect Oriented Database is being created and it will have the goal of simplifying use cases involved with data management. Typically, this is related to the model in an MVC architecture, or the domain model in SOA. Building an application with an AODBMS will motivate alternative choices when designing an architecture for your application.

Architecture impacts with framework usage: many web frameworks provide a controller implementation which simplifies your application development effort. There are many persistence frameworks that simplify the effort of storing an object in a relational database.

MVC is orthogonal to your business concerns. The MVC architecture divides the concerns of your application into three categories. Concerns can be modeled fitting this approach, but there is some divergence from the true concept to make it fit into such a structure. There are typically more than three kinds of concepts that an application needs to deal with The MVC breakdown is an effort at mapping your application's classes into these kinds of types.

AOP allows for the implementation of design patterns are first class language structures

An application is created to satisfy business goals. A business lives within a domain of concepts.

MVC was created as an approach to controlling complexity. The partitioning of concerns into this triad is simple and should be understandable by a large community of developers. As applications become more complex, this complexity must be addressed with various techniques.

Models

Reduction

Partitioning

Frameworks

Design Patterns

AOP

AOP has tradionally been associated with modularizign behavior that is scattered accross a system. So what does AOP have to do with data management? There are many things that an application needs to do with it's data. Discovery of the objects, managemnt of it's state, navigation of relationships, and other things. But there are many patterns found in persistent information that require extra fields of columns in a relationsl database in order to implement the concepts. For example a revision history of an object, such as a warehousing application would add effect start and end times to the row and make a new row for each update. This can be expressed as an aspect of the object under revision. The aspect data is orthogonal to the application data, that is it is seperate from, but united by the need of the feature applied to the object. An aspect oriented database would have native support for this feature (concern).

Wednesday, February 28, 2007

Persistent Data Aspects

If a database has persistent data that comes from an aspect, what would it be? Examples of this would be design patterns implemented as an aspect, metadata about an object, or other data that is introduced by the aspect. Also, a data "feature" will change the way data is stored in the database. The feature of a "revision history" is implemented as an aspect of the persistent data. The feature changes the persistence of a regular object to contain the modification time, and the prior instances.

In order to access the revision history of an object that has the feature of versioning, an aspect query syntax is needed to provide access to the custom information. an example of a query that returns the sequence of instances that represent the change history of an object could be:
select aspect(Version) from Customer where customerId = "12345"
This would match against the customer extent finding the instance that has a customerId of 12345, and returns the result defined by the "Version" aspect. This could be an envelope containing the instance at the time of a modification, and the time modified as a collection.

The result of accessing an object redefined by a "Version" aspect will depend on it's context. The normal usage would be just like any other object access. But what if you want to access the view of the object at a prior point in time? The context time of the query can be modified and the same query that provides a normal object could return the value of the object at the context time. The query can be reusable accross different contexts with different meanings.

A RDBMS typically supports triggers that are procedures that are executed at certain events within the database. This is a very normal aspect oriented flow. So, an aspect oriented database would not run a trigger, but just advice at the certain event defined by the DBMS. Also, the design pattern of an observer can be implemented as an aspect that would introduce a relationship between the subject and observer. The modification of the subject sends events to the observer(s). This is the same pattern as a trigger, but in an AODBMS the paradigm of thought is advice and design patterns as reusable aspects.

Aspect Query Language

An aspect oriented database should support an aspect oriented query language. What would the aspect paradigm do to influence other query languages? There is SQL, JDOQL, EJBQL, OQL, and others. AQL or "Aspect Query Language" would be a query language that supports queries against an aspect oriented database. There are persistent aspects, and persistent data that has been annotated by aspect introduced metadata. An aspect oriented database is a regular database that contains metadata or out of band data integrated with objects. Sure anydatabase can create metadata tables and join it to another table. So what is special about the aspect metadata? In part is a matter of representation, that is there will be keywords distinguishing the aspect data from the object data. The other side of the power of aspect data management is the implicit introduction of information based on contexts of the usage of objects in relationships.

Sunday, January 07, 2007

Contextual Relationships

The real world if full of context that introduces meaning into our data. DBMS systems can benefit from the management of these contexts and a representional approach to defining what the meaning related contexts are.

What is a relationship? There are two parties, and a rolle that describes the relationship. So a customer could be related to an address with the roll of billing address. But the same customer could be related to another address with a different role called sales address. There could be even more address-customer relationships with different roles. So what if you just said customer has an address. and that is all you need to know (as a user of "customer")? The role of the relationship is describing it's context.

There are two sides to this situation. There is the user of an information model, and the author of the information model. Both want it simplest for themself. Traditional techniques for defining relationships with many roles or contexts are that the structure contains the names of the role as the field name defining the relationship. There are maybe totally seperate models for a sales domain and for a billing domain, so sometimes the model never even integrates these concepts together.

Why not try to have the best of both worlds? That is for a user, just refer to th4e address as the address, and the author can determine what the various kinds of customer-address relationships can exist. This is a ternary relationship. If this is to be used in SQL, the queries to navigate such a model would become too burdensom to be usable to a wide audience.

Sunday, October 08, 2006

What is an Aspect Oriented Database?

An aspect oriented database is an object oriented database that supports the concepts of aspect orientation. An object oriented database is a relational database that supports the cpncepts of object orientation. So everyone knows what an RDBMS is? A tabular approach to defining data that is to be persisted or stored for long term storage and retrieval. Tables can be related to each other by queries that use fields from one table as keys to another table. Queries applied to these fields can make the data in the database correspond to a larger structure that can be defined as ann object model. An object oriented class diagram can be implemented in an RDBMS by mapping fields to collumns, and relationships to columns and by creatign extra tables to manage the relationships between many to many relations between classes. The various types of relationships, that is associations, aggregation can be mapped with hints such as cascade delete so that when a containing row is deleted, the child objects that connect to that row get deleted as well. This resempls an aggregation relationship. An object oriented database would provide a declarative approach to indicating that the relationship is a certain kind of relationship of type "aggregation". Object orentated databases support the notions of OO as direct concepts in the database. As well, they integrate naturally into the programming environment of the language they are supporting.

So the first description of an AODBMS is that it fits naturally into an aspect oriente4d programming language. Aspect oriented languages support concerns that are cross cutting. This means that a programming dependency occurs in many places of the program. This concept applied to a database would be that an aspect oriented database supports directly the concerns of data management accross multiple classes. One such example of a crosscutting data concern would be that "all tables have a column time_modified". This is needed to suport the export and tracking of what has been exported to another location. The crosscutting concern is that the modification time column is placed on many tables, and the value is updated to be the time of the last commit to that row. This can be concidered a "feature" of tables or classes that exist withing the context of an application. Time_modified is not really a domain value of a "customer". So should it be placed in a table called "customer"? Instead concider maybe the time_modified should be available to the query engine, and tracked for all objects in the classes in the "CRM" context. So the data declaration for CRM could be CRM.classes.time_modified. If the field is moved to an aspect that woudl define the feature of ModifiedObjects, then the ability to query this would need to be supported, so an AODBMS would support a query language that allowed queries based on this new "field", but it isn't realy a customer field, but just a filter value bound to the customer.

Saturday, August 12, 2006

Orthogonal Data is Aspect Oriented

What is a database? A place to store information that can retrieve that information at a later time. An RDBMS is the most popular form of "database". But a bunch of tables isn't an intuitive way to represent information. We are taught that it is, but is this really true?

Did you ever think that putting time modified information along with customer name, and other customer data was wrong? I think that a better way to define data would be to seperate the various types of data from each other in the persistence model declaration. So you would create a customer object definition or "table", and it would not have application types of information in the customer table. The query language would provide access to whatever the application might need, but the customer definition would be clean. The domain data is orthogonal to application data, and should not be intermingled into the same definition. This is the aspect oriented way to define data.

Wednesday, July 26, 2006

Aspect Oriented Data Management

I will be bringing my ideas on a new way to manage database data. Why should AI systems be the only place where sophisticated representations of data exist? The trend towards AOP is inevitable. Aspect Oriented Database Management will bring a new world of possibilities to applications and the industry of domain models.

Labels