Friday, August 15, 2008
ProtoSOA
Next steps will be to complete a thorough QA process while continuing to design for future capabilities. The next stage will bring some exciting features such as BPEL for workflow management, drag & drop interface, and auto-discovery.
Friday, May 16, 2008
Distractions
If anyone would like to offer their advice and expertise on the usage of OpenLDAP to create a somewhat complex Schema architecture, I would appreciate your comments. I am not up to speed yet on this technology but I'm working to overcome my own lack of experience.
In the meantime, I'm hoping to complete this design soon, after which I plan to join up with Tom and continue work on my "child". Next post, hopefully, I'll get back to the topic of this blog and perhaps think of some words of wisdom.
Wednesday, March 26, 2008
ProtoSOA Update
In the next few months, my colleague and I will once again join the development team in Beijing to continue developing the first full public release of the product. I would like to recognize the efforts of the ComFrame Beijing office for all they have done toward building a quality product. This is a fine group of engineers who have proven to be a very valuable asset to ComFrame. Their efforts have not gone un-noticed in our company circles.
By year's end, I hope to report that ProtoSOA has begun an "SOA (R)Evolution" in the software industry. More to come...
Saturday, December 1, 2007
ProtoSOA
At any rate, the current happenings on my plate are concerned with a new software product a colleague and I have been designing called "ProtoSOA". ComFrame Software is positioned to expand this design into a working product.
ProtoSOA™ is a Dynamic Enterprise Service Framework for Service Oriented Architecture (SOA) enablement. It is designed to allow business architects to define standard web services through metadata using administrative tools. The metadata not only provides the service descriptions, but also provides semantic mappings between canonical business terminology and “system terms” which are embedded in code. ProtoSOA not only exposes services that are fully compliant with current web service interoperability standards, it also seamlessly interacts with business process orchestration tools and provides the data transformation, transport, versioning, reliable messaging, security, auditing, and integration capabilities expected for an enterprise-class service bus.
If you would like to find out more about this product, please respond to this post.
That's all I have time for... later.
Wednesday, October 24, 2007
UML Training
UML, therefore, is a visual expression and expansion of the use case model. The use case model is a reflection of the system requirements, and the UML model expands upon this model. It is beneficial to achieve both behavioral and structural views of the use case model using UML. Structural views manifest themselves as class diagrams, component diagrams, and collaboration diagrams, while behavioral views are manifested by activity diagrams, sequence diagrams, and state machines. Additionally, it is helpful to have a good mix of these diagram types -- each one is intended to address a specific viewpoint or level of detail.
Structural models address the "static" view of things. For example, class diagrams express the structure of classes, their associations with other classes, and their inheritance hierarchy. Behavioral models address the dynamic interaction of things in the system. For example, a sequence diagram emphasizes the messages between objects in a scenario, especially the sequence of those messages. It is very important to address both the structure and the behavior of objects in a system.
Another useful view is the State Machine, which is primarily used to express the complex behavior exhibited by a class, especially when the class exhibits different behavior depending on its state.
I have found that the most useful progression of UML modeling is as follows:
1) Begin with the use case model.
2) Expand the use case model using Activity diagrams.
3) Identify the "things" in the system. These are most evident by looking for nouns in the use cases and activity model. These are classes, modeled (of course) by a Class diagram.
4) Examine the simple behaviors of each class and how each class collaborates with other classes. Document these behaviors as operations on each class (in the Class diagram) and as collaborations (in the Collaboration diagram).
5) Document each scenario in which message sequence is critical by using a Sequence diagram.
6) In cases where objects exhibit complex, state-dependent behavior, use a State Machine.
For completed systems, use the Component and Deployment diagrams to depict the physical implementation and relationships among nodes.
Thursday, October 11, 2007
It also seems to me that some of them don't really believe in it. Maybe they understand the benefits from an academic perspective, but having never actually lived in a "process pure" environment, they see software development processes as intrusive and weighty.
The truth is, software development is chaotic by nature. The questions of "how do we begin", "how do we know when we are done", "what are our deliverables", and "what is quality" seem basic. However, it is surprising how often development projects are undertaken without understanding what these things mean. Even when process evangelists are involved from the beginning, when the team fails to follow the process systematically the project will begin to degrade toward chaos.
A good development process does not have to be heavy. The most important features (use case driven development, visual modeling, and iterative development) can be tailored to the project and the project team.
Following a USDP can lend order to the chaos. It provides focus to the development effort. Everyone on the team has a common mental picture of what must be done, how it should be done, what is being produced, how the components relate to each other, and how to know when they are done and done correctly. Even when things start to degrade, as they often do when schedules and budgets get tight, a good development process is self-healing. It provides the disciplines needed to regroup and re-focus the team, mitigate risks, resolve unforeseen issues, and establish corrective measures.
Actually putting the USDP into practice is the key to understanding its benefits. Once you have been on a development team whose focus is USDP, you will never want to do things the "old way" again.
Friday, September 28, 2007
My GNU Public Key
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.2 (MingW32)
mQGiBEaJVpoRBAC7aD0MH+QpFj0FzZZ/A0eUIK6f0YxgueT2jHKcQqRhQzigimXi
Ztsg9YVGF+xpC2OJ9za/I6GNpG4kdI4+JhWWzKeKPygGTmx/xjA5tzGJX4zQAtGQ
af25S6jW1xEBJI81gGAvcTllbe6rKrFHHkYCN0dlBRtWg+H3fcNUetT05wCgvdJY
ipkBV7VTo9qZ2TlpOug0WRcD/2lL2r3i+buBe72FKpvCOfo3W3px8zPAywlryeC1
me2SAjWp4JxT9bE8GCcP5hXMJanlESO963xxgM7pig6riZUFe/fmrhgpUmm+PGns
rxScRVdhbNRewa2pPrrbWIrykMJAZHCabc5AX/QLLQ83VpaZB54Hn58Lv3jsiqVQ
ABZjBACiPR4IrqDh1+oNl/ILimtv4Wpv42LD4O4f8vGFQtc3Rh19Soo2H2qX3zyJ
vdmyW6ZLfoJkGZfw34UXTBesPkZlx8QPFCL/QaTwqXU9QYWxP223NGpPouOG4Na3
4JIpFYjM8gXboyhKF3D57DGMq0rFDoPj/+J0OZavK2BlccSNzbRQQmlsbCBXcmln
aHQgKFRoaXMgaXMgbXkgdmVyeSBzcGVjaWFsIENvbUZyYW1lIHB1YmxpYyBrZXkp
IDxid3JpZ2h0QGNvbWZyYW1lLmNvbT6IWwQTEQIAGwUCRolWmgYLCQgHAwIDFQID
AxYCAQIeAQIXgAAKCRCEy9mEvjZ9SNrFAKChXVTk5pGx6ntDrCm9/2oYkuQqYgCf
UNTylzchwpQhDJz6XXuV7J9fIuG5AQ0ERolWnBAEAPsP8fWX+FoIQVhST/TySD4w
mbn8UsGD9UCPe7EfJKsGfVeteAQsU8+PUPxqDviSxnlSaouUftZl44Xt5KT3qKGX
PZdkcr9xjt5Y2+C2Qdd94mnTMj+WdtfeviXHzkRWo+HrJPygONGTB0zFwiVsuLJu
c1v+/C3xUVwcIEdjxq4/AAMHA/9I+G5UxOIS1GMFMblsz9lq7YGlkceIb4cKixpM
n9oMP0BQMKVnVnW3kOfFQaY69CE0BCmVK+k7Xh49EqaZ34KuWrXNSGkYF8r2saHB
YUyR0B+oEdIWF9JhC2FjA2M5BiPOGmU6OGSDzq8zmc6eZBq6FyCdeU2/dKzSOBTw
9F+VJohGBBgRAgAGBQJGiVacAAoJEITL2YS+Nn1IH8oAnjx0JWw2DdcoY316L5j9
G3GYYEXBAJsGhz569+k1AKmxzKVNGMhyWcx5bg==
=/RXh
-----END PGP PUBLIC KEY BLOCK-----